Cross-checking disambiguated product line variability models

Many industry sectors face the challenge of how to satisfy the increasing demand for individualized software systems and software-intensive systems. The software product line (PL) engineering paradigm (SPLE, see [5]) has proven to empower organizations to develop a diversity of similar systems at lower cost, in shorter time, and with higher quality compared to single system development [5]. Key to SPLE is to exploit the commonalities of the systems that belong to the PL and to handle the variability (i.e., the differences) between those systems. Commonalities are properties and qualities that are shared by all systems of the PL [1]; e.g., all mobile phones let users make calls. In SPLE, two kinds of variability can be distinguished: Software variability and PL variability. Software variability refers to the “ability of a software system or artefact to be efficiently extended, changed, customized or configured for use in a particular context” [7]. This kind of variability is well known from the development of single systems. As examples, an abstract Java super-class allows different specializations to be used where the superclass is used; an interface allows different implementations to be chosen. PL variability [1, 5, 3] is specific to SPLE and describes the variation between the systems that belong to a PL in terms of properties and qualities, like features that are provided or requirements that are fulfilled. It is important to understand that defining PL variability, i.e., determining what should vary between the systems in a PL and what should not, is an explicit decision of product management (see [3, 5]). As an example, product management might have decided that the mobile phones of their PL should either offer the GSM or the UMTS protocol. A challenging task in SPLE is to map the PL variability to software variability. This means that the reusable artefacts from which the systems of the PL are built (called the core assets, which constitute the PL platform [5]) should be constructed flexibly enough to allow for efficiently and effectively building those systems [2, 6]. The decisions to be made are crucial and mutually influence each other: which systems to offer as part of the PL (i.e., what the scope of the PL should be [6]), and how to design the reusable artefacts to support this scope [3]. A lack of flexibility in the reusable artefacts, or a scope that lacks awareness of the technical realizability, can severely undermine the SPLE process. At best, timeconsuming and expensive changes of the reusable artefacts or the scope will be required. Therefore, it is essential to ensure that PL variability and software variability are consistent from the beginning. But since all changes cannot be anticipated, co-evolution of both variabilities over time should be facilitated too. In this presentation, we will introduce language and tool support for these tasks. To disambiguate the documentation of variability, we propose to record PL variability and software variability in separate models and to interrelate them. We use Feature Diagrams and Orthogonal Variability Models (OVM) respectively. Equiped with formal syntax and semantics, those models are amenable to automatic analysis in isolation. But, most importantly, since the cross-links between them are also formalized, the models can be crosschecked. We devise a set of checks that are straightforward for the stakeholders to interpret, like whether all planned systems of the PL can be realized, or whether the flexibility of the reusable artefacts is useful. A prototypical implementation relying on a SAT solver is reported. This presentation is based on a paper by the same authors that was recently published in the proceeding of the 15th IEEE International Symposium on Requirements Engineering (RE’07) [4].